---
# common items for the releng-* boxes
lvm_size: 100000
mem_size: 4096
num_cpus: 2
nm: 255.255.255.0
gw: 10.5.126.254
dns: 10.5.126.21

ks_url: http://10.5.126.23/repo/rhel/ks/kvm-rhel-7
ks_repo: http://10.5.126.23/repo/rhel/RHEL7-x86_64/

# Use the infra-testing repo
testing: True

# These are for fedmsg publication from the bodhi backend.
# If you change these iptables rules, you also need to changes the endpoints
# list in roles/fedmsg/base/templates/endpoints-bodhi.py
tcp_ports: [
    3000, 3001, 3002, 3003, 3004,
    3005, 3006, 3007, 3008, 3009,
    3010, 3011, 3012, 3013, 3014,
    3015, 3016, 3017, 3018, 3019,
]

# Make connections from signing bridges stateless, they break sigul connections
# https://bugzilla.redhat.com/show_bug.cgi?id=1283364
custom_rules: ['-A INPUT --proto tcp --sport 44334 --source sign-bridge01.phx2.fedoraproject.org -j ACCEPT']

# With 16 cpus, theres a bunch more kernel threads
nrpe_procs_warn: 900
nrpe_procs_crit: 1000

host_group: bodhi2

# These people get told when something goes wrong.
fedmsg_error_recipients:
- bodhiadmin-members@fedoraproject.org

# These set a config value in /etc/fedmsg.d/, see roles/bodhi2/base/
# They are both true for the single bodhi-backend node in stg.
bodhi_masher_enabled: True
bodhi_updates_handler_enabled: True
bodhi_signed_handler_enabled: True

# These are consumed by a task in roles/fedmsg/base/main.yml
fedmsg_certs:
# This first cert is used by the push-tool.   releng members run it and it fires
# off a simple fedmsg message that the masher (running as fedmsg-hub) is
# listening for.  It then does all the worker.
- service: shell
  owner: root
  group: masher
  can_send:
  - bodhi.masher.start
  - logger.log
# These are certs for the masher to publish its own messages as it progresses.
- service: bodhi
  owner: root
  group: masher
  can_send:
  - bodhi.mashtask.complete
  - bodhi.mashtask.mashing
  - bodhi.mashtask.start
  - bodhi.mashtask.sync.done
  - bodhi.mashtask.sync.wait
  - bodhi.errata.publish
  - bodhi.update.eject
  - bodhi.update.complete.testing
  - bodhi.update.complete.stable
  - bodhi.update.request.testing
  - bodhi.update.request.stable
  - bodhi.update.request.batched
  - bodhi.buildroot_override.untag
- service: ftpsync
  owner: root
  group: ftpsync
  can_send:
  - bodhi.updates.epel.sync
  - bodhi.updates.fedora.sync

fas_client_groups: sysadmin-releng,sysadmin-bodhi
sudoers: "{{ private }}/files/sudo/00releng-sudoers"


# For the MOTD
csi_security_category: Moderate
csi_primary_contact: Releng Admins sysadmin-releng-members@fedoraproject.org
csi_purpose: Run the Bodhi masher.
csi_relationship: |
    The mashing of repos here happens as part of the 'fedmsg-hub' daemon.  Check
    logs with 'journalctl -u fedmsg-hub'.  Check the bodhi masher docs/code for
    more detail on what it does:
    https://github.com/fedora-infra/bodhi/blob/develop/bodhi/consumers/masher.py

    * This host relies on:
      * db01 for its database, which is shares with the bodhi2 frontend nodes.
      * An NFS mount of koji data in /mnt/koji/
      * The fedmsg bus for triggering mashes.
      * XMLRPC calls to koji for tagging and untagging updates.
      * bugzilla for posting comments about status changes
      * the wiki for getting information about QA "Test Cases"
      * taksotron (resultsdb) for getting status-check results (gating updates).

    * No other systems rely directly on this host.  Everything depends on it
      indirectly for the creation of new updates repos (which get synced out to
      the master mirror for distribution.
